업무 규칙

: 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙, 또는 절차

즉 컴퓨터상으로 구현했는지와 상관없이 사업적으로 수익을 얻거나, 비용을 줄일 수 있어야 한다. 심지어 사람이 수동으로 직접 수행하더라도 마찬가지다.

: 사업 자체에 핵심적이며 규칙을 자동화하는 시스템이 없더라도 그대로 존재

ex) 대출에 N% 이자를 부과한다는 사실은 은행이 돈을 버는 업무 규칙. 컴퓨터로 계산 혹은 사람이 직접 계산하던지 하등의 관계가 없다.

: 핵심 업무 규칙이 요구하는 데이터.

시스템이 자동화되지 않은 경우에도 존재한다.

ex) 대출에 필요한 대출잔액, 이자율, 지급 일정 같은 데이터.

핵심 규칙 + 핵심 데이터 = 객체 (엔티티)

시스템 내부 객체로써 핵심 업무 데이터를 기반으로 동작하는 일련의 핵심 업무 규칙을 구체화한다. 핵심 업무 데이터를 직접 포함하거나, 쉽게 접근 할 수 있다. 또한 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성된다.

factory method pattern

대출을 뜻하는 Loan 엔티티의 UML 클래스로 세가지의 핵심 업무 데이터를 포함하며, 세가지 핵심 업무 규칙을 인터페이스로 제공한다.

엔티티를 생성 할 때 업무에서 핵심적인 기능을 구현하는 소프트웨어는 모으고, 구축 중인 나머지 모든 고려사항과 분리시킨다. 이 클래스는 업무의 대표잘오서 독립적으로 존재하며, 데이터베이스, 사용자 인터페이스, 프레임워크 등의 고려사항에 인해 오염되서는 안된다.

핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다.

: 자동화된 시스템이 사용되는 방법

factory method pattern

엔티티 내의 핵심 업무 규칙과는 반대로, 애플리케이션에 특화된 업무 규칙을 설명한다.
유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 언제 호출할지를 명시하는 규칙을 담는다. 즉 엔티티를 제어한다.
또한 유스케이스는 사용자 인터페이스를 기술하지 않는다. 유스케이스만 보고서는 웹을 통해 전달되는지, 콘솔 기반인지 아니면 순수한 서비스인지 알 수 없다.
즉 유스케이스는 시스템이 사용자에게 어떻게 보이는지를 설명하지 않는다. 오직 애플리케이션에 특화된 규칙만을 설명하며 사용자와 엔티티 사이의 상호작용을 규정한다.
유스케이스는 객체다. 업무규칙을 구현하는 하나 이상의 함수를 제공하며 데이터 요소를 포함한다.
엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못한다.

엔티티 - 고수준 개념, 다양한 애플리케이션에 사용될 수 있도록 일반화.

유스케이스 - 저수준 개념 , 단일 애플리케이션에 특화, 시스템의 입력과 출력에 보다 가깝게 위치

유스케이스는 입력 데이터를 받아 출력 데이터를 생성한다. 제대로 된 유스케이스 객체라면 데이터를 사용자나 다른 컴포넌트와 주고받는 방식에 대해 전혀 눈치챌 수 없어야 한다.

유스케이스는 단순한 요청 데이터 구조를 입력으로 받고, 단순 응답 데이터 구조를 출력으로 반환한다. 이들 데이터 구조는 어떤 것에도 의존하지 않는다.

요청 응답 모델이 독립적이여야 하며, 엔티티 객체를 가리키는 참조를 요청 및 응답 데이터 구조에 포함해서는 안된다.

업무 규칙은,

Clean Architecture - Item 20